Subject: Re: Why does c.o clear BSS? It's not needed!!
From: [email-masked] (Doug Walker)
Date: Mon, 25 Apr 1994 12:36:18 GMT
Newsgroups: comp.sys.amiga.programmer

In article <[email-masked]>, "Boris Folgmann" <[email-masked]> writes:
|> Why does c.o clear BSS? In the AutoDoc for InternalLoadSeg() you find:
|> [...]
|> Clears unused portions of Code and Data hunks (as well as BSS hunks).
|> (This also applies to LoadSeg() and NewLoadSeg()).
|> [...]

If you're talking about SAS/C's c.o, it clears memory because the OS didn't 
do it until AmigaDOS 2.0.

|> BTW: Why don't place everything in one CODE hunk?
|> 
|> Assembler Example:
|> 
|> Start:  move.l (ReturnCode,pc),d0
|>         rts
|> 
|> ReturnCode: dc.l        10
|> Storage:    dx.l        5

For one thing, I don't see why it's an advantage to have everything in
one CODE hunk.  However, that point aside, there are several reasons
for having multiple hunks:

   1. If you have a NEAR data hunk, you can use 16-bit offsets relative
      to register A4 instead of full 32-bit relocations.  You could use
      PC-relative offsets in the code hunk, but you'd be limited to
      32k for your program PLUS your data.  With a seperate near section,
      you get 64k of near data independant of code size.  The 16-bit
      offsets are faster and allow compiler-implemented reentrancy (cres.o).

   2. CHIP data obviously has to go into a seperate section.  You don't
      want your code taking up CHIP memory.

   3. Putting the stuff in seperate sections reduces the size of any
      one section; this means that in fragmented systems, you have a 
      better chance of being able to load the program.  If you have a 
      program with 300k of code and 200k of data, but your system only
      has two 400k chunks available, a single hunk won't load; two 
      hunks would load.

-- 
  *****                    / [email-masked]
 *|_o_o|\\     Doug Walker<  BIX, Portal: djwalker
 *|. o.| ||                \ CompuServe: 71165,2274
  | o  |//     
  ====== 
Any opinions expressed are mine, not those of SAS Institute, Inc.